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REMARKS 

The Office Action mailed May 27, 2009, considered and rejected claims 1, 2, and 4-32. 
Claims 1-2, and 4-32 were rejected under 35 U.S.C. § 103(a) as being unpatentable over 
Arakawa et al. (U.S. Patent No. 7,222,172) in view of Robe et al. (U.S. Patent No. 7,506,040). 1 

By this response, claims 1, 2, 4, and 9 are amended, claims 33-42 are added, and claims 8 
and 13-32 are canceled. The new claims are computer storage medium equivalents of the system 
claims. 2 Support for the amendments may be found primarily in paragraphs 8, 9, and 23-26 of 
the specification. 

The current amendments have been made to better clarify the structure of the 
synchronization system of the present invention. For example, the synchronization system of the 
present invention includes a sync runtime, a sync controller, and sync adapters. The sync 
runtime provides the functions that are used to perform the synchronization. The sync controller 
receives profiles from applications that desire to perform synchronization and generates sync 
adapters to match the profiles. The sync adapters perform the actual synchronization of data 
using the sync runtime. See |t 23-26. In short, "the present invention relates to a framework 
that promotes consistent and manageable synchronization across all back end data stores that 
synchronize with a particular data store." \ 1. 

As stated in the independent claims, an application program defines a profile for a sync 
adapter. This profile specifies a local folder that serves as the source and destination of changes 
in the replicas, and one or more conflict resolution policies. With this information, the sync 
controller is able to create an adapter that will perform synchronization in a manner that meets 
the specified requirements. A benefit of this system is that a user may specify the parameters for 
synchronization in the profile and the sync controller can generate an appropriate adapter to 
synchronize with any of multiple different back end databases (e.g. Exchange, Hotmail, Active 
Directory, Sync ML stores, Etc.). The details of how the synchronization occurs is handled by 
the sync adapter in conjunction with the sync runtime module, thus freeing the application from 

1 Although the prior art status of the cited art is not being challenged at this time, Applicant reserves the right to 
challenge the prior art status of the cited art at any appropriate time, should it arise. Accordingly, any arguments and 
amendments made herein should not be construed as acquiescing to any prior art status of the cited art. 

2 The specification has been amended to redefine computer readable media as two separate types of media: computer 
storage media and communication media. Computer storage media encompasses physical storage devices such as 
RAM, ROM, and optical devices. Therefore, Applicant submits that the new claims are directed to statutory subject 
matter that does not encompass signals. 
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much of the overhead while still providing consistency even between disparate back end 
databases. Further, synchronization is facilitated using the concept of knowledge. By using 
knowledge, a replica only needs to be aware of changes that have been made to the replica rather 
than tracking the changes of every replica in the sync community. To synchronize with another 
replica, the replica sends its knowledge to the other replica for comparison with the other 
replica's knowledge. In this manner, the other replica can easily determine any items that the 
replica has not seen and transmit these items back to the replica for synchronization. This use of 
knowledge also enhances the consistency of synchronizing across multiple disparate back ends. 

The Arakawa reference on the other hand is not specifically directed to synchronizing in 
the same manner as the present invention. Arakawa is directed to making backups of a primary 
storage volume. The backup is performed using the snapshot function which makes a copy of 
the primary volume and copies it to the secondary volume. Col. 8, lines 51-56. Once the 
snapshot is taken, the two volumes are kept in sync by propagating changes to the primary 
volume to the secondary volume as soon as the changes are made. Col. 8, line 62 - Col. 9, line 
2. In another embodiment, rather than propagating changes immediately, update information 
may be stored on the primary volume and then synchronized at a later time to the secondary 
volume. Col. 9, lines 1 1-25. Arakawa does not disclose anything similar to the structure of the 
present invention which allows an application to instantiate an adapter by specifying a profile to 
a sync controller. Also, Arakawa also does not disclose anything similar to the sync runtime 
module with which the sync adapter communicates to perform the actual synchronization of a 
replica that is maintained by the application. For these reasons, Arakawa fails to teach or suggest 
various limitations of the independent claims. 

In addition, Arakawa does not disclose the synchronization of replicas using knowledge 
as in the present invention. The snapshot feature of Arakawa isn't the same as knowledge. For 
example, the snapshot either takes a complete copy of the primary volume and copies it to the 
secondary volume, or tracks incremental changes and propagates them individually or in a batch. 
In other words, in Arakawa, there is no comparison of the knowledge of the secondary volume 
with the knowledge of the primary volume to determine what changes need to be propagated. 
This is best illustrated by the fact that changes are not made independently to the secondary 
volume. The secondary volume merely acts as a backup to the primary volume. In contrast, in 
the present invention, each replica can be updated independently. Thus, changes may be made to 
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the second replica that have not been made to the first replica and vice versa. This does not 
happen in Arakawa. The following example illustrates this distinction. Using the present 
invention, a user may keep his contact lists synchronized even though he updates them 
independently at work and at home. For example, a user may add a new contact on his home 
computer, and using the present invention, this change would be synchronized to his work 
computer so the new contact is available on his work computer the following day. A further 
update made at work would also appear on his home computer when he gets home. In contrast, 
using the snapshot function of Arakawa, a user may update his contacts at work. These updates 
could then be backed up to a secondary volume (i.e. copy the data image to a server). If his 
computer were to crash, the backup on the secondary volume could be used to restore the 
computer; however, the backup would never contain further updates that were made 
independently of the computer. In short, Arakawa and the present invention are very different. 
Arakawa, therefore, fails to teach or suggest the knowledge aspect of the independent claims. 

Rabe likewise fails to teach or suggest each limitation of the independent claims. Rabe is 
directed to storing data, and particularly to connecting disparate storage devices over a network. 
The primary feature of Rabe is the data conversion mechanism that translates proprietary data 
models into a standard or "common data model." Col. 2, lines 35-65. This conversion facilitates 
the interconnection of different devices that would not otherwise be compatible. Rabe does not 
disclose a synchronization system containing a sync controller, sync adapters, and sync runtime 
module as claimed. Rabe also does not disclose anything similar to the knowledge of the present 
invention. Therefore, the combination of Arakawa and Rabe fails to teach or suggest each 
limitation of the independent claims. 

In view of the foregoing, Applicant respectfully submits that the other rejections to the 
claims are now moot and do not, therefore, need to be addressed individually at this time. It will 
be appreciated, however, that this should not be construed as Applicant acquiescing to any of the 
purported teachings or assertions made in the last action regarding the cited art or the pending 
application, including any official notice. Instead, Applicant reserves the right to challenge any 
of the purported teachings or assertions made in the last action at any appropriate time in the 
future, should the need arise. Furthermore, to the extent that the Examiner has relied on any 
Official Notice, explicitly or implicitly, Applicant specifically requests that the Examiner 
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provide references supporting the teachings officially noticed, as well as the required motivation 
or suggestion to combine the relied upon notice with the other art of record. 

In the event that the Examiner finds remaining impediment to a prompt allowance of this 
application that may be clarified through a telephone interview, the Examiner is requested to 
contact the undersigned attorney at (801) 533-9800. 

Dated this 27 th day of August, 2009. 



Respectfully submitted, 

/Brian D. Tucker/ 

RICK D. NYDEGGER 
Registration No. 28,651 
BRIAN D. TUCKER 
Registration No. 61,550 
Attorneys for Applicant 
Customer No. 47973 
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